Literals for user-defined types

This note proposes a notion of user-defined literals based on literal constructors without requiring new syntax. If combined with the separate proposal for generalized initializer lists, it becomes a generalization of the C99 notion of compound literals. Basically, a constructor defines a user-defined literal if it is inline and specifies a simple mapping of its arguments to object representation values and is invoked with constant expressions or objects that can be trivially copied (such as pointers). The Problem C++ does not provide a way of defining literals for user-defined types. Instead, constructors are used. For example: 15 // int literal "15" // string literal (zero terminated array of characters) complex(15) // “sort of complex literal” When a constructor is simple and inlining is done well, such constructor calls provide a reasonable substitute for literals. However, a constructor is a very general construct and there have been many requests for a way to express literals for user-defined types in such a way that a programmer can be confident that a value will be constructed at compile time and potentially stored in ROM. For example: complex z(1,2); // the variable z can be constructed at compile time const complex cz(1,2); // the const cz can potentially be put in ROM A Solution The most direct and obvious solution would be to introduce syntax to distinguish a literal constructor and to distinguish literals of user-defined types. For example: class X { int x,y,z; public: literal X(int a, int b) :x(a+1),y(0),z(b) {} // literal constructor // ... }; X"1,2" // a literal of type X This syntax is just for the illustration of the idea; a better syntax is suggested below. This “literal constructor” illustrates the requirements for any specification of a literal for a userdefined type. It specifies a (simple) mapping from a set of arguments to the representation of the type. Often, that will simply specify a value for each member of the type's representation, but slight generalizations are possible and sometimes useful. Here, I have indicated that the member y's value need not be specified by the user and that a slight transformation takes place on the argument used to specify a (x becomes a+1). The body is empty. Since the construction of the representation of a value takes place at compile time, very few constructs could reasonably be allowed in a literal constructor body. The simplest rule would be to require that body to be empty. That is, the mapping of arguments to representation (member values) must be specified as member initializers. In addition, a literal constructor must be inline. What can be accepted as an argument type? An argument must of a type that can be copied without the use of a nontrivial copy constructor (e.g. ints, pointers, and references). What can be accepted as an initializer? An initializer can be another argument, a value of a type that can be copied without the use of a non-trivial copy constructor, or a constant expression. Note that this definition is recursive in that it allows the use of literals of user defined types as arguments to be used. For example: class Y { complex x, y; literal X(complex a, int b) : x(a), y(complex"a,0") {} // ... }; const int c = 3; Y"complex"1,2",c"; This simple definition could be elaborated. For example, should we accept floating point expressions, such as d+1.7 where d is an argument of floating point type? I think not. Even if d is a literal so that the expression to be evaluated is something like 2.3+1.7, I suspect that the complication of requiring floating point arithmetic at compile time is not worth the bother – especially for cross compilers. Syntax for user-defined literals The syntax used to illustrate the idea of a “literal constructor” above has some obvious problems. Consider that last use: const int c = 3; Y"complex"1,2",c"; That use of quotes (chosen to emphasize the literal nature of the construct) would clearly confuse any traditional lexer (and many human readers). Also, it doesn't exactly extend to string literal arguments. Furthermore, it would not be easy to get used to the idea that elements of the string-like part are separate values and that variable can occur there. I think that a much more natural (i.e. familiar) and readable notation would use parentheses: const int c = 3; Y(complex(1,2),c); After all, parentheses are the way we usually express arguments. However, by doing so, we lost the syntactic distinction of the literal. That is,